1. Field of the Invention
This invention relates to methods of obtaining low power operation for a telecommunications device using a telecommunications protocol, especially a wireless protocol, such as the Bluetooth protocol, to apparatus and software for carrying out such methods, and in particular to providing low power operation when a telecommunications device such as a Bluetooth slave device is has a radio link in Sniff mode.
2. Discussion of the Related Art
Bluetooth is a well known short-range radio link intended to replace the cable(s) connecting portable and/or fixed electronic devices. Full details are available from Bluetooth SIG which has its global headquarters in Overland Park, Kans., USA. Key features are robustness, low complexity, low power, and low cost. Bluetooth operates in the unlicensed ISM band at 2.4 GHz. Frequency hopping is applied to combat interference and fading. A slotted channel is used with a nominal slot length of 625 μs. On the channel, information is exchanged through packets. In Bluetooth version 1.1 each packet is transmitted on a different hop frequency. In Bluetooth version 1.2 it is proposed that transmission and receive packets may be sent on the same frequency. The Bluetooth protocol uses a combination of circuit and packet switching. Slots can be used for asynchronous operation or can be reserved for synchronous packets. Descriptions of the Bluetooth standards can be found in “Discovering Bluetooth”, M. Miller, Sybex, 2001; “Bluetooth: connect without cables”, J. Bray and C. F. Sturman, Prentice-Hall, 2001 as well as from the Bluetooth standards themselves.
Wireless Bluetooth devices are often battery powered and can support an HID (Human Interface Device) profile and can act as a slave device. Typically, such battery powered HID devices are:                Bluetooth wireless keyboard        Bluetooth wireless mouse        Bluetooth wireless game controller        
The Bluetooth system can provide a point-to-point connection (only two Bluetooth units involved), or a point-to-multipoint connection. In the point-to-multipoint connection, the channel is shared among several Bluetooth units. Two or more units sharing the same channel form a piconet. One Bluetooth unit acts as the master of the piconet, whereas the other unit(s) acts as slave(s). Up to seven slaves can be active in the piconet. In addition, many more slaves can remain locked to the master in a so-called parked state. These parked slaves cannot be active on the channel, but remain synchronized to the master. Both for active and parked slaves, the channel access is controlled by the master. Units can also be in a hold mode or a sniff mode.
The best battery operated device dedicated for most applications is the one that has the lowest power consumption and so the longest battery life time without any degradation in functionality. Any possibility to save power consumption must be considered by the designer. The Bluetooth specification has defined a few low power modes. Possible BT low power modes are: hold, sniff and park.
Hold mode allows devices to be inactive for a certain time. It does not affect synchronous traffic. During hold mode all asynchronous traffic is stopped for a specified period of time. It is left entirely up to a held device if it switches off its receiver during the hold period. A parked device gives up its active member address and ceases to be an active member of a piconet. It cannot transmit in park mode nor can it be actively addressed by a master unit. It wakes up periodically to listen for transmissions from the master device at pre-arranged beacon instants. The master unit transmits to slave units using a periodic beacon. As the beacon messages receive no reply from parked slave units, the beacon is simply transmitted at regular intervals. The slave units use the beacon messages to synchronize their internal clocks. Both a master and a slave unit may send messages to end the park mode. A parked slave unit can sleep during beacon signals. This is set by the master which tells a slave unit how long it can sleep by specifying the number of beacon signals NBsleep it can sleep through. A parked unit may make use of a less accurate low power oscillator so the timing may drift away if the parked unit remains asleep too long. To make sure all parked slave units stay synchronized a master unit can unpark and park them at regular intervals.
Similar to the park mode, a slave in sniff mode periodically wakes up to listen to transmissions from the master and to re-synchronize its clock offset. For the HID profile, when devices are active (currently in use) the sniff mode is commonly used. The nature of HID devices are as such that a data flow might be required at each moment. For this reason the park and holdmode are not so suitable for these kind of devices, while the sniff mode is well suited. In the sniff mode, the duty cycle of the slave's listening activity can be reduced. If a slave participates on a link, it has to listen in every slot to the master traffic. With the sniff mode, the time slots where the master can start transmission to a specific slave is reduced; that is, the master can only start transmission in specified time slots. These so-called sniff slots are spaced regularly with an interval of Tsniff. Thus, the sniff mode may be described as the provision of periodic moments in time when communication from the master can occur, these times being at longer intervals than available during normal operation. The sniff parameters, interval and attempts, are always initiated by the slave HID device. The slave HID device will always select the sniff parameters. It must always choose the parameters such that the data rate it receives data is lower than the data rate it can report to the master and take care that the latency to sent the data is within the limits the application requires. So, the master starts polling the slave at the sniff interval for a number of sniff attempts. In case the slave device has got no data to send it replies with a NULL packet otherwise it replies with the data packet. The slave starts listening at the sniff slots for Nsniff attempt consecutive receive slots unless a packet with matching address is received. After every reception of a packet with matching address, the slave continues listening at the subsequent Nsniff timeout or remaining of the receive slots, whichever is greater. So, for Nsniff timeout>0, the slave continues listening as long as it receives packets with matching address. To enter the sniff mode, the master or slave can issue a sniff command message. This message will contain the sniff interval Tsniff and an offset Dsniff. The timing of the sniff mode is then determined. It is known to vary the parameters Tsniff and Nsniff according to backlogs of data to be transmitted between each of a number of different slaves, to save overall power consumption of the slaves. In Bluetooth version 1.2 the Nsniff timeout is used after the slave has transmitted a data packet. The Nsniff timeout is not used when only POLL/NULL packets have been exchanged.
NULL packets can be sent by a master and used by the slave to maintain synchronization. The POLL packet is very similar to the NULL packet. It does not have a payload either. In contrast to the NULL packet, it requires a confirmation from the recipient. Upon reception of a POLL packet the slave must respond with a packet. This return packet is an implicit acknowledgement of the POLL packet. The Poll packet can be used by the master in a piconet to poll the slaves, which must then respond even if they do not have information to send.
As mentioned, the master polls the slave. In the case that it didn't receive any reply within a link supervision time it will declare the link as lost—a link supervision timeout. Also at the slave, the slave replies to the poll packets. In the case it didn't receive any poll packet within the link supervision time it will declare the link as lost.
Synchronization is important for ad-hoc connections. In the Bluetooth system, each unit has a free-running native clock which has an accuracy of 20 ppm when the unit is active and 250 ppm when the unit is in a low-power mode. When a unit wants to page another unit, it can speed up the connection establishment when it knows the recipient's native clock. This clock information should be stored during a previous connection stage. A Bluetooth unit can thus have a list of unit addresses with corresponding native clocks it can use when paging one of those units. The clock information is stored as a time offset to its own native clock. When a piconet is in operation, it is the native clock in the master that determines the timing. The slaves add an offset to their native clocks in order to be hop synchronized to the master. The slave's native clock plus the offset with respect to the master provide the proper input to the hop selection scheme. Since the native clocks of the master and the slave are free-running, the offset in the slaves has to be adjusted continuously to compensate for drift. The reception of packets sent by the master is used to adjust the offset. The access code in front of the packet has the proper autocorrelation properties to enable a slave to derive the timing.
A master needs to send a poll packet occasionally, to maintain its awareness of other slaves within range, and to maintain synchronization of such slaves. The number of poll packets sent should be kept to a minimum to avoid the power cost of causing these slaves to have to transmit. Transmitting usually costs more power than receiving and so contributes to draining the batteries of units which are presumably trying to save power by being in the sniff mode. Where resources are scarce and must be used in an efficient way the ratio of the number of POLL and NULL packets to the number of data packets should be minimized. Besides this efficiency goal, a polling master in Bluetooth should also be fair. In the Bluetooth best effort case, fairness implies that slaves get the same fraction of their fair share of communication time where the fair share is determined by rules.
For scheduling POLL packets during Sniff mode, several scheduling algorithms are known and are in use in commercially available devices. The more advanced algorithms stop scheduling POLL packets (and start scheduling NULL packets) in the sniff attempts when the slave has synchronized (i.e. when the slave did respond with a NULL packet). In other words when the slave has synchronized, it is sufficient to send NULL packets for the remaining master Tx slots of the sniff attempts. This algorithm is not suitable for implementations that are using a “prescheduling algorithm”. In “prescheduling implementations”, Tx/Rx packet pairs are allocated in advance. For a master (using a prescheduling algorithm) of a Bluetooth link in sniff mode, this means that the master does not know in advance (i.e. at the time the actual scheduling occurs) when the slave will be synchronized. One possible solution to this problem is to send POLL packets in every Tx slot of the Sniff attempts, but this costs transmit power at the slave side (since the slave is obliged to respond to POLL packets).
A Bluetooth device has the lowest power consumption in the case where it can run on a low power oscillator clock, also referred to as the deep sleep mode. Unfortunately, activating or deactivating this power mode requires some time. The ideal situation is that the device can go into the deep sleep mode in between the sniff intervals. Unfortunately, for most devices the sniff interval is too short in active mode to allow such a power down. For this purpose a so-called inactivity timer is used. That is, the inactivity timer is restarted each time a data packet needs to be sent to the master. In case that the inactivity timer expires one will renegotiate the sniffed link to go into another sniffed link with a higher sniff interval. And perhaps that this sniff interval allows now the device to go into the deep sleep power mode. Driving the inactivity timer to the limit is thus a way to lower power consumption.
Changing sniff intervals during operation is not without risk. The inactivity timer is used to change sniff intervals into longer periods on expiration. In case that there is back application activity detected the device must go as fast as possible back to a sniffed link which meets the latency requirements. This usually means going into sniff mode with the smallest sniff interval. In the event that this negotiation time takes too long it might be that the device cannot report all the data it needs to. The Bluetooth specification doesn't provide any hard figures for response times to renegotiate the sniff parameters. Also, initiating a new sniffed link requires first to unsniff the existing link and next to sniff the link back. There is no other way to change the sniff parameters than this. The negotiation time on link manager level to go from a slow sniff to a fast sniff is implementation dependant. If this takes too long there is a risk that (since the device receives data that it needs to sent) the device has got no buffer space left anymore such that it needs to throw away valid data—this is the worst that can happen. This fact makes that interoperability testing for HID devices is still required.
In summary an HID device can go into several sniff states and low power modes so that making a good HID device with a very low power consumption is difficult. It requires a lot of device tuning, testing, debugging and interoperability testing.